48. 谨慎使用流并行

　　考虑条目 45 中的程序：

　　在我的机器上，这个程序立即开始打印素数，运行到完成需要 12.5 秒。假设我天真地尝试通过向流管道中添加一个到 parallel() 的调用来加快速度。你认为它的表现会怎样?它会快几个百分点吗?慢几个百分点?遗憾的是，它不会打印任何东西，但是 CPU 使用率会飙升到 90%，并且会无限期地停留在那里 (liveness failure:活性失败)。这个程序可能最终会终止，但我不愿意去等待；半小时后我强行阻止了它。

　　这里发生了什么？简而言之，流类库不知道如何并行化此管道并且启发式失败（heuristics fail）。 即使在最好的情况下，如果源来自 Stream.iterate 方法，或者使用中间操作 limit 方法，并行化管道也不太可能提高其性能。 这个管道必须应对这两个问题。更糟糕的是，默认的并行策略处理不可预测性的 limit 方法，假设在处理一些额外的元素和丢弃任何不必要的结果时没有害处。在这种情况下，找到每个梅森素数的时间大约是找到上一个素数的两倍。因此，计算单个额外元素的成本大致等于计算所有先前元素组合的成本，并且这种无害的管道使自动并行化算法瘫痪。这个故事的寓意很简单：不要无差别地并行化流管道（stream pipelines）。性能后果可能是灾难性的。

　　通常，并行性带来的性能收益在 ArrayList、HashMap、HashSet 和 ConcurrentHashMap 实例、数组、int 类型范围和 long 类型的范围的流上最好。 这些数据结构的共同之处在于，它们都可以精确而廉价地分割成任意大小的子程序，这使得在并行线程之间划分工作变得很容易。用于执行此任务的流泪库使用的抽象是 spliterator，它由 spliterator 方法在 Stream 和 Iterable 上返回。

　　流管道终端操作的性质也会影响并行执行的有效性。如果与管道的整体工作相比，在终端操作中完成了大量的工作，并且这种操作本质上是连续的，那么并行化管道的有效性将是有限的。并行性的最佳终操作是缩减（reductions），即使用流的 reduce 方法组合管道中出现的所有元素，或者预先打包的 (如 min、max、count 和 sum)。短路操作 anyMatch、allMatch 和 noneMatch 也可以支持并行性。由 Stream 的 collect 方法执行的操作，称为可变缩减（mutable reductions），不适合并行性，因为组合集合的开销非常大。

　　如果编写自己的 Stream，Iterable 或 Collection 实现，并且希望获得良好的并行性能，则必须重写 spliterator 方法并广泛测试生成的流的并行性能。编写高质量的 spliterator 很困难，超出了本书的范围。

　　并行化一个流不仅会导致糟糕的性能，包括活性失败（liveness failures）;它会导致不正确的结果和不可预知的行为 (安全故障)。 使用映射器（），过滤器（filters）和其他程序员提供的不符合其规范的功能对象的管道并行化可能会导致安全故障。 Stream 规范对这些功能对象提出了严格的要求。例如，传递给 Stream 的 reduce 方法操作的累加器（accumulator）和组合器（combiner）函数必须是关联的，非干扰的和无状态的。如果违反了这些要求（其中一些在第 46 项中讨论过），但按顺序运行你的管道，则可能会产生正确的结果; 如果将它并行化，它可能会失败，也许是灾难性的。

　　沿着这些思路，值得注意的是，即使并行的梅森素数程序已经运行完成，它也不会以正确的 (升序的) 顺序打印素数。为了保持顺序版本显示的顺序，必须将 forEach 终端操作替换为 forEachOrdered 操作，它保证以遇出现顺序（encounter order）遍历并行流。

　　重要的是要记住并行化流是严格的性能优化。与任何优化一样，必须在更改之前和之后测试性能，以确保它值得做（详见第 67 条）。理想情况下，应该在实际的系统设置中执行测试。通常，程序中的所有并行流管道都在公共 fork-join 池中运行。单个行为不当的管道可能会损害系统中不相关部分的其他行为。

　　如果在并行化流管道时，这种可能性对你不利，那是因为它们确实存在。一个认识的人，他维护一个数百万行代码库，大量使用流，他发现只有少数几个地方并行流是有效的。这并不意味着应该避免并行化流。在适当的情况下，只需向流管道添加一个 parallel 方法调用，就可以实现处理器内核数量的近似线性加速。 某些领域，如机器学习和数据处理，特别适合这些加速。

　　在我的机器上，使用此功能计算π（10⁸）需要 31 秒。只需添加 parallel() 方法调用即可将时间缩短为 9.2 秒：

　　换句话说，在我的四核计算机上，并行计算速度提高了 3.7 倍。值得注意的是，这不是你在实践中如何计算π(n) 为 n 的值。还有更有效的算法，特别是 Lehmer’s formula。

　　总之，甚至不要尝试并行化流管道，除非你有充分的理由相信它将保持计算的正确性并提高其速度。不恰当地并行化流的代价可能是程序失败或性能灾难。如果您认为并行性是合理的，那么请确保您的代码在并行运行时保持正确，并在实际情况下进行仔细的性能度量。如果您的代码是正确的，并且这些实验证实了您对性能提高的怀疑，那么并且只有这样才能在生产代码中并行化流。